Internet communication no longer necessarily consists of two endpoints exchanging messages over a dumb packet-forwarding core. Rather, data is frequently processed by intermediary middleboxes like caches, compression proxies, intrusion detection systems, or virus scanners. For example, all four major U.S. mobile carriers use HTTP proxies and a typical enterprise network has roughly as many middleboxes as it does routers and switches. However, as the use of encryption online increases (as of 2014, nearly half of all Web flows used HTTPS), these middleboxes become “blind” to the content of the traffic and hence can no longer perform their jobs. This has prompted both the academic community and industry to consider the question: how do we integrate middleboxes into secure communication sessions?
Because TLS, the standard secure communication protocol used in the Internet, is designed for exactly two parties, the current practice is to split the connection into two separate TLS connections: the middlebox impersonates the server to the client and opens a second connection to the server. But doing so drastically weakens security, in part because the client cannot explicitly authenticate the middlebox and also cannot be sure that the middlebox properly authenticated the server. Recently, proposals like Multi-Context TLS (mcTLS) have addressed this by allowing endpoints to explicitly authenticate one another as well as the middlebox.
However, the picture is complicated by an emerging middlebox deployment model: outsourcing middlebox functionality to third parties such as ISPs or third party cloud providers who offer middleboxes as-a-service. This promises the cost benefits of economy of scale and frees network administrators from configuring and managing multiple specialized boxes. But it also poses a new challenge: the owner of middlebox software (middlebox service provider) and the owner of the hardware it runs on (infrastructure provider) are not the same. If the infrastructure is untrusted, existing protocols like split TLS and mcTLS cannot provide the standard security properties TLS gives us today because, firstly, session data and keys are visible in memory, and secondly, the endpoints cannot tell if infrastructure provider actually ran the code the middlebox provider intended it to.
One known idea is to protect session data from infrastructure providers using new cryptographic techniques. BlindBox and Embark have introduced new techniques that allow middleboxes to directly process encrypted data. These works are based on pattern matching the encrypted data without decrypting it.